In telecommunication systems, large databases are used for storing various data in different data entries for subscribers or users of communication terminals, which can be retrieved by authorised requesting parties such as other terminal users, applications, services and various network nodes. In this description, the term “requesting party” is used to generally represent any entity retrieving data from a database.
The data stored may relate to, e.g., the translation or mapping of telephone numbers, subscription settings, terminal specifications, user preferences, etc. Entries in the database for a certain type of data contain such data for all users, where each data entry is typically associated with a specific user. Data may also be stored in this manner for entities other than individual users, such as user groups, services, network nodes and equipment elements, generally referred to as “objects”.
Performing major modifications in such databases for a large number of data entries of corresponding objects can be associated with various problems, e.g. relating to performance, flexibility, consistency, time for deployment and workload.
For example, if a certain type of data is to be updated and replaced by another type of data for a multitude of objects in a database, e.g. the mapping of circuit—switched telephone numbers and packet-switched addresses for subscribers, the data entries must be changed one by one and the changes will thus progress through the database at a limited rate. If these changes are made while the database is active and available for data queries, some data entries will be updated but not others, resulting in inconsistency and potential data retrieving errors. For a very large database, it may take some time before this process is completed.
In the case of a configuration error or the like, it may further be necessary to make a “rollback” of executed updates, which is limited by the time it takes to undo the individual data entries one by one. In some cases, it may even be necessary to keep the database closed for requests until all entries have been updated properly to avoid errors and inconsistency. The new data entries could also be made available from a completely new database as they are added while the original database is closed, i.e. no data will be available from the non-updated entries.
Another obvious alternative when changing the data type is to keep the original database running as is, if possible, while building a new separate database by adding data entries for all subscribers, and then instantly switch from the original database to the new one when completed. In the latter case, the original database can be replaced with the new updated one in a single operation to avoid inconsistency and errors, but deployment of the new type of data in the system will then of course be delayed for all subscribers until the new database is completed.
Furthermore, in this known solution, two databases must be maintained before the new database can be activated and the old one is closed, which means that any provisioning operations must be made in both databases to keep them synchronised. In the new database, all entries must be created regardless of whether the old entries are changed or not. This alternative is thus not suitable when only a fraction of the entries are to be updated in an otherwise large database, due to the workload of copying the same data from the old database into the new database for the other entries.
Thus, selecting either of the above alternatives gives no room for flexibility with respect to how and when the new data is made available. It may also be desirable to present one type of data to certain requesting parties and another type of data to others which is rather complicated, if not impossible, to do in the known database systems.
FIG. 1 illustrates how a database 100A with original data entries 102A is replaced by a new separate database 100B with modified data entries 102B. In the original database 100A, data entries #1, 2, 3 . . . hold data X1, X2, X3 . . . , respectively, for individual objects, e.g. users in a telecommunication system. For example, each data entry may be headed by an identity for a subscription such as a traditional PSTN (Public Switched Telephone Network) telephone number, and the data X held in the entry may be a corresponding SIP (Session Initiation Protocol) address valid for that subscription, i.e. number mapping. The subscription identity can then be used as a key to the data entry when placing a data query.
The figure illustrates that the new database 100B is created by adding a data entry for each object, modified or not, where Data X1 in entry #1 is replaced by Data Y1, Data X2 in entry #2 is replaced by Data Y2, and so forth. In this way, the new modified database 100B is gradually built up, and when all data entries have been stored, database 100B can be activated for data queries in replacement of database 100A. Alternatively, the original database 100A can be kept closed while building the new one, and only the currently added entries in the new database 100B are available during the time it takes to complete the database 100B. As mentioned above, for entries not to be updated/modified, the same data must still be copied into the new database 100B.
FIG. 2 illustrates generally how a database system 200 can be operated. A database 202 contains multiple data entries for different objects, such as telecommunication users. A database operator can control the contents in the database 202 by means of a provisioning logic unit 204 that includes a suitable interface for entering operator commands and various data to be stored. The operator may thus input information to update the contents in the database 202 by adding, deleting or changing entries, generally referred to as “updates”. The operator may also create an entirely new separate database, not shown, to replace an existing one as described above.
The database system 200 further contains a first querying logic unit A and a second querying logic unit B, both being adapted to handle data requests from requesting parties and to place corresponding data queries to the database 202, as shown, in order to obtain data and deliver suitable responses to the requesting parties.
As mentioned above, the present solutions for making database updates can be awkward to use and may be associated with, e.g., unwanted delays, limited flexibility, inconsistency and/or poor availability. Thus, it is not possible to perform time-instant modifications of individual data entries in large datasets without reducing the availability or introducing errors. The database systems of today have no simple flexible mechanism for controlling the availability or access to different data types for different viewers, e.g. to present different views or versions of data of the same object(s). Moreover, the option for making a “rollback” of executed updates, e.g. in the case of a configuration error, is limited by the time it takes to undo the individual data entries one by one.